This invention relates generally to computer systems, and more particularly to a mechanism for optimizing processing of client requests.
On the Internet or World Wide Web, information is generally communicated on a request-response basis. That is, a client (typically running a browser program) submits a request to a server for a particular resource. In response, the server performs whatever tasks are necessary to service the request (e.g. access and execute the resource), and then provides one or more sets of content back to the client. The client thereafter renders the content to a user. This request-response sequence, referred to as a xe2x80x9croundtripxe2x80x9d, is carried out for each request.
In processing a client request, the server proceeds through a number of different phases. The particular phases implemented by the server may differ from server to server, but some common phases include the authorization translation (AT) phase, the name translation (NT) phase, the path check (PC) phase, the object-typing (OT) phase, the service (SE) phase, the logging phase (LO), and the error (ER) phase.
In the AT phase, the server determines whether the particular client submitting the request is authorized to access the server. Unless this determination is answered in the affirmative, no further processing of the request is performed (except for error processing). In the NT phase, the server translates the logical universal resource locator (URL) of the request into a physical pathname on the server""s file system. For example, the http://server name/ part of the request may be translated into a directory pathname, such as D:/Server/docs. This translation makes it possible to actually access a resource on the server. In the PC phase, the server checks the pathname derived in the NT phase to determine whether the particular client submitting the request is authorized to access the specific resource specified in the pathname. It is possible for a client to have authorization to access the server generally but not to have authorization to access a particular resource on the server. The PC phase checks for this possibility. Unless it is determined that the client is authorized to access the requested resource, the client request will not be serviced.
In the OT phase, the server determines the MIME (Multipurpose Internet Mail Extensions) type of the request. The MIME type has three attributes: type, encoding, and language. These attributes affect the manner in which the server processes the request, and the form in which the response will be provided to the client. In the SE phase, the server actually services the request. In doing so, the server may invoke one or more service subsystems provided by the server to provide the resource requested by the client. The type attribute determined during the OT phase may be used in determining which service subsystem to invoke. At the end of the SE phase, a response is sent back to the client. In the LO phase, the server adds entries to a set of log files. These log entries document the processing of the request. Finally, in the ER phase, the server processes any errors that occurred during the processing of the request. The ER phase is implemented only if one or more errors occurred in one of the preceding phases.
In processing a request, the server executes one or more directives in each of the phases. As used herein, the term directive refers broadly to any instruction or command that is recognized by the server and that causes the server to take some action. These directives in turn cause one or more functions to be invoked/performed. Together, the functions of the various phases operate to process the request and to generate a response to the client. In proceeding through the various phases, the server typically uses a configuration file as a guide. The configuration file contains, for each phase, all of the directives that may be executed in that phase. The server steps through these directives, phase by phase, directive by directive, and selectively executes certain directives to process the request. The particular directives executed by the server may, and mostly likely will, vary from request to request, depending upon the request.
With reference to FIG. 1, there is shown a pictorial representation of a sample configuration file 100 used in processing a request. As shown, the configuration file 100 comprises a plurality of entries, with each entry representing a directive. Each directive specifies a phase and a function. The phase (e.g. AT, NT, etc.) indicates the phase to which the directive pertains, and the function is the function that is invoked when the directive is executed. In addition, a directive may optionally further specify a condition and a set of parameters. The condition specifies the condition that needs to be met before the directive is executed, and the parameters provide the parameters that will be used when the function is invoked. As shown in FIG. 1, each phase may comprise a plurality of directives. Depending upon the phase, all of the directives pertaining to that phase may be executed, some of the directives may be executed, or just one directive may be executed. Which directives are executed, and how many, are controlled by the server.
As noted above, the server steps through the directives, phase by phase, directive by directive, to process a request. To illustrate how this is done, a sample processing of a request will now be described. In processing a request for a particular resource, the server begins with the AT phase. In this phase, all of the pertinent directives are executed to ensure that all authorization conditions are tested. Thus, the server executes each of the AT directives in the configuration file 100. These directives are executed one after the other in the order set out in the configuration file 100. As each directive is executed, a corresponding function is invoked. If any error is encountered during the execution of any of the functions (thereby meaning that the client is not authorized to access the server), then all further processing of the request is halted, and the ER phase is entered. The directives in the ER phase are then executed to generate errors messages that are returned to the client. If no errors are encountered, then the AT phase will complete successfully, and the server will proceed to the NT phase.
In the NT phase, the server executes only one directive. Once an NT directive is executed, the server moves on to the PC phase. In determining which NT directive to execute, the server steps through each NT directive (beginning with the first) and determines whether the condition(s) for that directive is satisfied by the current request. If the condition(s) is not met, thereby meaning that the directive does not apply to the current request, then the server proceeds to the next NT directive and repeats the same process. This continues until an applicable NT directive is found and executed. Unless there is an error in the configuration file, an applicable NT directive will be found and executed for every request. Since only the first applicable NT directive is executed, the ordering of the NT directives in the configuration file 100 is important. Once an NT directive is executed, thereby causing a corresponding function to be invoked, the server exits the NT phase and proceeds to the PC phase.
As with the AT phase, all of the directives in the PC phase are executed to ensure that the client has full authorization to access the requested resource. If any error is encountered during the execution of any of the PC directives (thereby meaning that the client is not authorized to access the requested resource), then all further processing of the request is halted, and the ER phase is entered. The directives in the ER phase are then executed to generate errors messages that are returned to the client. On the other hand, if no errors are encountered, then all of the PC directives are executed to complete the PC phase. Once the PC phase is completed, the server proceeds to the OT phase. As with the PC phase, all of the directives in the OT phase are executed. Once all of these directives are executed, the server proceeds to the SE phase.
In the SE phase, the request is actually serviced. More specifically, the requested resource is access and processed, and a response is provided to the client. In servicing the request, the server executes just one of the SE directives. To determine which SE directive to execute, the server steps through each directive (beginning with the first) and determines whether the condition(s) for that directive is satisfied by the current request. For example, if the current request is for a cgi resource, the server determines whether the directive applies to cgi resources. If an SE directive does not apply to the current request, then the server proceeds to the next SE directive and repeats the same process. This continues until an applicable SE directive is found and executed. Unless there is an error in the configuration file 100, an applicable SE directive will be found and executed for every request. Once an SE directive is executed, thereby causing a corresponding function to be invoked, the request is serviced. Thereafter, the server sends a response to the client, exits the SE phase, and proceeds to the LO phase. In the LO phase, all of the LO directives are executed to log the processing of the request into the server. Once that is done, processing of the request is completed. This overall process is repeated for each and every request.
As the above discussion shows, a significant amount of processing is performed to process each request. Some of this processing, for example, the execution of the directives, is necessary. However, some of the processing is just overhead for enabling the proper directives to be executed. Examples of this overhead include the searching for the applicable NT and SE directives, and the processing of the configuration file 100. For a small number of directives and a small number of requests, this overhead is fairly negligible. However, with many directives and many requests (as is usually the case with large complex systems), the overhead can become significant. In fact, it can become so significant that it degrades system performance. Since performance degradation is clearly an undesirable result, it is desirable to minimize this overhead as much as possible. Currently, however, there is no effective mechanism for doing so.
To overcome the shortcomings of the prior art, the present invention provides an improved mechanism for processing client requests. According to the present invention, the first time a client request for a particular resource is received by a server, it is processed using the configuration file as described above. As the request is processed, a list of executed directives is compiled. This list of directives represents just the directives that were actually executed during processing, and does not include the directives which were determined not to apply to the request. In effect, the list represents a trace of the processing of the request. Once the list of directives is compiled, it is stored for future reference. The next time a request for that same resource is received, the configuration file is not consulted. Instead, the stored list of directives is accessed and used to process the request. More specifically, all of the directives on the list are executed in turn to process the request. Since these are the same directives as those executed in the processing of the prior request, the subsequent request will be processed properly.
Note that the processing of the subsequent request is carried out much more efficiently than the first. Unlike the first request, there is no need to open or to step through the configuration file. There is also no need to step through the directives themselves to determine which directives apply to the request. The applicable directives have already been determined. All that needs to be done is to execute them. By processing all requests after the first in this manner, most of the request processing overhead is eliminated. By removing unnecessary overhead, the present invention significantly increases the efficiency of the request processing process. Hence, the present invention represents a significant improvement over the prior art.